모든 개발자의 실무를 위한 필수 기본기 클래스 자료집

# 전략적으로 Git 사용하기 - Gitflow

이번 글에서는 프로젝트를 진행할 때 Git을 사용하는 전략 패턴 중 하나인 Gitflow 전략을 알아봅시다.

TIP

대표적인 브랜치 전략으로 GitFlow 이외에도 GitHub-flow, Gitlab-flow 등이 있습니다. 각기 장단점이 있기에 회사 개발 팀에서는 상황에 맞는 브랜치 전략을 정해서 사용하곤 합니다.


# Git의 전략적 활용

보통 하나의 프로젝트에 여러 명의 개발자가 참여합니다. 같은 직군들이 모인 팀일 수도 있고 프론트엔드, 백엔드, QA 개발자 등 다양한 직군의 개발자들이 함께할 수도 있습니다. 이때 여러 사람이 개발과 테스트를 할 때 어떻게 진행하면 좋을까요?

가장 간단하게는 하나의 Git 브랜치 위에서 모두가 작업하는 방법이 있습니다. 그러나 remote repository 내용은 자주 바뀌게 될 것이며 최신 버전으로 동기화하기 위해 pull을 하게 되면 수시로 conflict 가 날 가능성이 높습니다. 또한 브랜치에 내 작업만 있는 것이 아니라, 쉽게 reset 하기도 어렵습니다.

더 나은 방법은 main 브랜치를 하나 두고 개개인이 작업할 브랜치를 지속적으로 만들어서 작업하는 것입니다. 이러면 개인의 작업만 브랜치에 남길 수 있고, 코드의 충돌과 변경에 대한 부담도 덜합니다. 그리고 해당 브랜치에서 생긴 변경사항들에 대해 리뷰도 받을 수 있습니다. 하지만 사람들이 각자 만드는 브랜치를 관리하기 어려워집니다. 브랜치 개수는 언제든 늘어날 수 있으며, 브랜치 이름 규칙도 정해지지 않아 관리가 어려워질 수 있습니다.

위와 같은 고민들 끝에, 협업의 관점에서 Git을 효율적으로 운영할 수 있는 전략들이 나오게 되었습니다. 그중 가장 대표적인 것이 바로 Gitflow입니다.


# Gitflow란?

# 프로젝트 개발 사이클

일반적인 개발 프로젝트 과정을 생각해보면 다음과 같이 대략적인 정형화된 사이클이 있음을 알 수 있습니다.

  1. 필요한 기능을 분석, 정의하고 개발합니다.
  2. 개발이 완료되면 테스트 환경에 배포합니다.
  3. 통합 테스트를 진행하며 버그 등 문제가 없는지 확인합니다.
  4. 문제가 있으면 이를 수정하고 2~3의 과정을 거칩니다.
  5. 테스트 완료 후에 최종적으로 운영 환경에 배포합니다.
  6. 최종 배포 후 며칠 뒤 심각한 버그를 발견하면 빠르게 수정하여 업데이트된 프로젝트를 배포합니다.

Gitflow는 이런 사이클을 고려한 하나의 패턴입니다.

# Gitflow 브랜치 전략

img

Gitflow는 다음과 같이 5개의 브랜치를 두도록 약속합니다.

  • master
    • 운영 환경에 최종 배포가 되는 프로젝트를 담는 브랜치입니다.
  • develop
    • 아직 배포하지는 않았지만, 기능 개발을 완료한 프로젝트를 담는 브랜치입니다.
    • master 브랜치로부터 파생됩니다.
  • feature
    • 필요한 각 기능을 작업하는 브랜치입니다.
    • 보통 feature/기능 으로 브랜치 이름을 짓습니다.
      • ex. feature/create_user
    • 실제 개발자들은 이 브랜치를 만들어 이 위에서 작업합니다.
    • develop 브랜치로부터 파생됩니다.
    • 해당 브랜치에서 작업을 완료하면 develop 브랜치로 머지됩니다.
  • release
    • 최종 배포 전 통합 테스트를 할 프로젝트를 담는 브랜치입니다.
    • develop 브랜치로부터 파생됩니다.
    • 테스트 중 발견한 버그 수정 역시 release 브랜치에서 이뤄집니다.
    • 테스트가 완료되면 master 브랜치와 develop 브랜치에 머지됩니다.
  • hotfix
    • 운영 환경 중 발견된 심각한 버그를 수정할 때 사용하는 브랜치입니다.
    • master 브랜치로부터 파생됩니다.
    • 버그 수정 후 master 브랜치와 develop 브랜치에 머지됩니다.

# 브랜치 흐름

전체적인 프로젝트와 브랜치 흐름은 다음처럼 이루어집니다.

  1. master 브랜치에서 develop 브랜치를 만듭니다.
  2. 필요한 기능 사항들을 정의하고 개발자들 별로 어떤 기능 개발을 담당할지 정합니다.
  3. 기능 사항 별로 각 개발자는 develop 브랜치에서 feature 브랜치를 만들어 작업합니다.
    • 실제로는 feature/create_user , feature/payment 등 한 번에 개발할 단위로 브랜치를 만듭니다.
    • 한 사람이 여러 브랜치를 담당할 수 있습니다.
    • 반대로 한 브랜치에 해당 기능 개발에 참여한 여러 사람이 작업할 수도 있습니다.
  4. feature 브랜치에서 작업 완료 후 remote repository에서 push 하여 팀원들에게 리뷰를 받습니다.
  5. 리뷰가 완료된 feature 브랜치는 develop 브랜치로 머지합니다.
  6. 정의했던 기능 사항들을 모두 개발하면 이제 develop 브랜치에서 release 브랜치를 만듭니다.
  7. 이 release 브랜치 위에서 통합 테스트를 진행합니다.
    • 보통 회사 내 QA팀이 있으면 QA팀에서 이런 테스트를 진행해줍니다.
    • 통합 테스트 중 발견된 버그는 release 브랜치 위에서 수정하고 커밋합니다.
  8. 통합 테스트를 마치면 master 브랜치와 develop 브랜치를 머지합니다.
  9. 마지막으로 master 브랜치의 최종 커밋에 tag를 달아 프로젝트 버전을 명시한 후 배포합니다.
  10. 이후에 최종 배포된 프로젝트에 심각한 버그가 발견했을 때 master 브랜치에서 hotfix 브랜치를 만들어 버그 수정 작업을 합니다.
  11. 버그 수정 작업 완료 후에는 master 브랜치와 develop 브랜치에 머지합니다.
  12. 버그 수정이 완료된 master 브랜치의 프로젝트의 최종 커밋에 다시 tag를 달아 프로젝트 버전을 명시합니다.

TIP

릴리즈 버전

팀에서 운영하는 프로젝트는 보통 주기적으로 배포(릴리즈)를 진행할 때마다 최종 커밋에 git tag를 활용해 버전을 붙입니다.

버전을 기록하는 방식도 Semantic Versioning같이 몇가지 대표적인 패턴들이 존재합니다. 자세한 내용은 아래 더 공부하면 좋은 것들에서 확인해보세요.

# 장단점

Gitflow 패턴을 사용하면 다음과 같은 장점이 있습니다.

  • 브랜치의 이름과 개수를 통일성 있게 가져갈 수 있습니다.
    • master, develop 브랜치는 항상 존재합니다.
  • 브랜치간 작업 흐름이 명확합니다.
    • feature -> develop -> release -> master 로 흐릅니다.
  • 브랜치를 명확하게 나눴기 때문에 브랜치별로 담당 팀을 명확하게 나눌 수 있습니다.
    • 예를 들어 feature/user 는 유저 관련 팀이, feature/payment 는 결제 관련 팀이 담당할 수 있습니다.
    • QA팀에게 release 브랜치에 있는 프로젝트만 제공할 수 있습니다.

한편 다음과 같은 단점도 있습니다.

  • 개발 팀의 규모나 개발 방식에 따라 5개의 브랜치를 관리하는 것이 부담스러울 수 있습니다.
    • 별도의 QA팀이 없고, 개발 팀이 직접 통합 테스트해야 하는 경우, 굳이 release 브랜치가 필요 없을 수도 있습니다.
      • develop 브랜치에 있는 내용으로 테스트하고 수정하는 게 더 빠를 수 있습니다.
  • 프로젝트가 항상 위와 같이 명확한 라이프사이클을 가지는 것은 아닙니다.
    • 해당 버전에 구체적인 스펙들을 정하고 개발을 하기보단, 필요에 따라 매번 기능을 즉각적으로 테스트하고 배포할 수도 있습니다.
    • 이 때문에 Gitflow는 주로 소프트웨어 공학론에서 말하는 애자일(agile)한 모델보다는, 폭포수(waterfall) 모델에 어울린다는 평도 있습니다.

TIP

실제로는 각 팀에 맞게 Gitflow 전략을 수정하여 사용합니다.

예를 들어, 각 브랜치 이름을 다르게 둔다거나, release 브랜치를 사용하지 않기도 합니다. 보통 master, develop, feature 브랜치 개념에 해당하는 식으로 브랜치를 활용하고 있으면 폭넓게 Gitflow라고 부르기도 합니다.


# 더 알아두면 좋을 내용

Last Updated: 2/20/2022, 1:51:31 PM

← 클린 코드 - 네이밍 →

CC-BY-NC-ND-4.0 Licensed | Copyright © 2021-present Grab